Improve error handling #310

gcatanese · 2025-10-06T11:55:15Z

When a validation error 422 is returned by the API

{
  "type": "https://docs.adyen.com/errors/validation",
  "title": "The request is missing required fields or contains invalid data.",
  "status": 422,
  "detail": "It is mandatory to specify a legalEntityId when creating a new account holder.",
  "invalidFields": [{"name": "legalEntityId", "message": "legalEntityId is not provided"}],
  "errorCode": "30_011"
}

the library doesn't raise an error, but it returns instead AdyenResult: it is then responsibility of the code calling the client to inspect the AdyenResult object and understand the type of error.

This pull request improves error handling in the Adyen Ruby client by replacing generic result objects with specific exceptions for common API errors (400, 422, 5xx). This makes error management clearer, more predictable, and easier to integrate, with dynamically generated messages from API responses.

gemini-code-assist · 2025-10-06T11:55:29Z

Summary of Changes

Hello @gcatanese, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the robustness and clarity of error handling within the Adyen Ruby client. By transitioning from returning generic result objects to raising specific exceptions for common API error codes (400, 422, and 5xx), it allows developers to more effectively catch and manage different types of API failures. This change streamlines error management, making the client more predictable and easier to integrate into applications that require precise error identification.

Highlights

Enhanced Error Handling: The client now raises specific exceptions for HTTP 400, 422, and 5xx status codes, moving away from returning a generic AdyenResult object for these error types.
New Error Types: Introduced Adyen::FormatError for 400 responses, Adyen::ValidationError for 422 responses, and Adyen::ServerError for 5xx responses, providing more granular error identification.
Refactored Error Classes: The Adyen::FormatError class was updated to specifically handle 400 errors, and a dedicated Adyen::ValidationError class was created for 422 errors, replacing a previous, less specific definition.
Comprehensive Testing: New test cases have been added to verify that the correct exceptions (Adyen::FormatError and Adyen::ValidationError) are raised with appropriate details for 400 and 422 API responses.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request significantly improves error handling by raising exceptions for 400, 422, and 5xx responses, which is a great change. The implementation is solid, and the new tests cover the client-side error cases well. I've provided a few suggestions to make the error handling even more robust by preserving the specific 5xx status code, correcting a minor typo in a test description, and adding test coverage for the new server-side error handling.

lib/adyen/client.rb

spec/client_spec.rb

lib/adyen/client.rb

sonarqubecloud · 2025-10-09T12:44:03Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
18.6% Duplication on New Code

See analysis details on SonarQube Cloud

gcatanese · 2025-10-16T11:45:43Z

/gemini summary

gemini-code-assist · 2025-10-16T11:46:05Z

Summary of Changes

This pull request significantly improves the robustness and clarity of error handling within the Adyen Ruby client. By transitioning from returning generic result objects to raising specific exceptions for common API error codes (400, 422, and 5xx), it allows developers to more effectively catch and manage different types of API failures. This change streamlines error management, making the client more predictable and easier to integrate into applications that require precise error identification, especially with the addition of dynamically generated error messages from the API response payload.

Highlights

Enhanced Error Handling: The client now raises specific exceptions for HTTP 400, 422, and 5xx status codes, moving away from returning a generic AdyenResult object for these error types.
New Error Types: Introduced Adyen::FormatError for 400 responses, Adyen::ValidationError for 422 responses, and Adyen::ServerError for 5xx responses, providing more granular error identification.
Dynamic Error Message Generation: A new helper method build_error_message was added to dynamically parse API response bodies (supporting both RFC 7807 and legacy formats) to construct more informative exception messages.
Refactored Error Classes: The Adyen::FormatError class was updated to specifically handle 400 errors, and a dedicated Adyen::ValidationError class was created for 422 errors, replacing a previous, less specific definition.
Comprehensive Testing: New test cases have been added to verify that the correct exceptions (Adyen::FormatError, Adyen::ValidationError, and Adyen::ServerError) are raised with appropriate details for 400, 422, and 500 API responses.

Changelog

lib/adyen/client.rb
- Updated the formatting of an ArgumentError message for better readability.
- Implemented new error handling logic within call_adyen_api to raise specific exceptions for HTTP 400, 422, and 5xx responses, using Adyen::FormatError, Adyen::ValidationError, and Adyen::ServerError respectively.
- Modified existing 401 and 403 error handling to utilize the new build_error_message helper for consistent message generation.
- Added a new private method build_error_message to dynamically construct detailed error messages by parsing the API response body, supporting both RFC 7807 and legacy error models.
lib/adyen/errors.rb
- Adjusted the Adyen::FormatError class to specifically handle HTTP 400 status codes.
- Introduced a new, dedicated Adyen::ValidationError class for HTTP 422 status codes.
- Removed the previous, less specific Adyen::ValidationError class definition.
spec/client_spec.rb
- Added new test cases to verify that Adyen::FormatError is correctly raised for 400 responses, including checks for message content and error codes.
- Added new test cases to verify that Adyen::ValidationError is correctly raised for 422 responses, covering both RFC 7807 and legacy error body formats.
- Added a new test case to verify that Adyen::ServerError is correctly raised for 500 responses, including checks for message content and error codes.

Activity

An initial summary of changes was provided by gemini-code-assist[bot].
SonarQube Cloud reported that the 'Quality Gate passed' for the pull request.
gemini-code-assist[bot] suggested using Adyen::APIError for 5xx responses to preserve the original status code, as Adyen::ServerError hardcodes the status to 500. This suggestion was not adopted in the final patch.
gemini-code-assist[bot] recommended correcting a test description for a 422 error test to accurately reflect the Adyen::ValidationError being tested. This suggestion was not adopted in the final patch.
gemini-code-assist[bot] suggested adding a test case for 5xx errors, proposing a test for Adyen::APIError. A test for Adyen::ServerError was added instead.
Reviewer galesky-a suggested parsing the JSON response body to generate more specific and dynamic error messages, citing the Adyen Java library as an example.
The author, gcatanese, agreed with galesky-a's suggestion and implemented the dynamic error message parsing, ensuring support for both RFC 7807 and legacy API error schemas.

gcatanese added 2 commits October 6, 2025 13:36

Define 400 and 422 errors

09a5d1f

Handle 400, 422, 500 responses

be551a7

gcatanese requested a review from a team as a code owner October 6, 2025 11:55

gcatanese added the enhancement New feature or request label Oct 6, 2025

gemini-code-assist bot reviewed Oct 6, 2025

View reviewed changes

lib/adyen/client.rb Outdated Show resolved Hide resolved

spec/client_spec.rb Outdated Show resolved Hide resolved

spec/client_spec.rb Outdated Show resolved Hide resolved

gcatanese added 2 commits October 6, 2025 15:05

Add response status in error message

1831771

Update test description

d172442

gcatanese requested a review from galesky-a October 7, 2025 08:27

galesky-a reviewed Oct 7, 2025

View reviewed changes

lib/adyen/client.rb Outdated Show resolved Hide resolved

Format error message using response payload

69aa873

gcatanese requested a review from a team as a code owner October 9, 2025 12:43

galesky-a approved these changes Oct 9, 2025

View reviewed changes

gcatanese merged commit a511b74 into main Oct 9, 2025
12 checks passed

AdyenAutomationBot mentioned this pull request Oct 7, 2025

Release v11.0.0 #308

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Improve error handling #310

Improve error handling #310

Uh oh!

gcatanese commented Oct 6, 2025 •

edited

Loading

Uh oh!

gemini-code-assist bot commented Oct 6, 2025

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sonarqubecloud bot commented Oct 9, 2025

Uh oh!

Uh oh!

gcatanese commented Oct 16, 2025

Uh oh!

gemini-code-assist bot commented Oct 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Improve error handling #310

Improve error handling #310

Uh oh!

Conversation

gcatanese commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist bot commented Oct 6, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sonarqubecloud bot commented Oct 9, 2025

Quality Gate passed

Uh oh!

Uh oh!

gcatanese commented Oct 16, 2025

Uh oh!

gemini-code-assist bot commented Oct 16, 2025

Summary of Changes

Highlights

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gcatanese commented Oct 6, 2025 •

edited

Loading